REMARKS 

Present Status of Application 

The Examiner is thanked for the thorough examination of the present application. 
The Office Action, however, has tentatively rejected all claims. Specifically, the Office 
Action has rejected claims 1-8 and 12-26 under 35 U.S.C. § 102(b) as allegedly anticipated 
by U.S. Patent 6,253,248 to Nakai (hereafter Nakai). The Office Action has also 
tentatively rejected claims 9-11 and 27-29 under 35 U.S.C. §103(a) as allegedly obvious 
over a selective combination of elements from Nakai and U.S. Patent 5,706,507 to Schloss 
(hereafter Schloss). For at least the reasons set forth below, Applicant submits that the 
rejections should be withdrawn. 



Independent Claim 1 

The Office Action rejected independent claim 1 under 35 U.S.C. § 102(b) as 
allegedly anticipated by Nakai. For at least the reasons set forth below, Applicant 
respectfully traverses these rejections. 

Claim 1 recites: 

1. A computer system comprising: 

one or more client computers connected to a global-area computer 
network; 

a transport gateway computer connected to the global-area 
computer network; 

a plurality of server computers connected to the transport gateway; 

and 

a transport gateway computer program executable by the transport 
gateway, the transport gateway computer program comprising computer 
instructions for: 

receiving a file transfer request from a client computer; 

selecting a repository on one of the server computers based 
on one or more routing tokens in the file transfer request, 
wherein the routing tokens include one or more attributes 
describing the file, the client computer or an originator of the file 
transfer request, and 

performing the requested file transfer. 
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{Emphasis added.) Applicant respectfully submits that the rejection is misplaced for at least 
the reason that the cited art does not disclose the features emphasized above. 

Specifically, among other features, claim 1 defines "selecting a repository on one of 

the server computers based on one or more routing tokens in the file transfer request, wherein 
the routing tokens include one or more attributes describing the file, the client computer or 
an originator of the file transfer request." The Office Action (paragraph No. 5) has alleged 
that this feature is taught in Nakai in col. 3-line 53 through col. 4, line 14, col. 5, lines 35-42, 
and col 7 line 37 - col. 8, line 9. Applicant respectfully disagrees. In contrast, this portion of 
Nakai actually states: 

The operation of the proxy server in FIG. 1 will be briefly 
described below. When the transmitter/receiver 101 has received a request 
from the client 107, the request is passed to the request 
interpreting/executing unit 102. The request interpreting/executing unit 
102 checks a protocol that the server as the destination of the request 
supports, and executes protocol conversion if necessary. 

In this case, information contained in the request from the client 
alone is often insufficient to execute conversion to the protocol that the 
destination server supports. In such case, information or the like on the 
user context holding unit 104 or local disk 108 is read out, or the setup 
window controller 106 presents the setup window on a display of the client 
107 to request the user to input necessary information, thus acquiring the 
information required for protocol conversion. 

The request interpreting/executing unit 102 inquires the server as to 
whether it has capability (resources) of satisfying the request or its 
resource state before it directly issues the request from the client to that 
server, and determines a server or system that can satisfy the request from 
the client most satisfactorily. 

In this way, the request interpreting/executing unit 102 issues a 
request after it specifies the necessary information and actual request 
destination, and then receives information sent back therefrom. Also, the 
request interpreting/executing unit 102 adds another information to the 
information sent back from the request destination, and sends them to the 
transmitter/receiver 101, which then sends back the data to the client 107. 

• * # 

The proxy server 100 receives a request from the client 107 by the 
transmitter/receiver 101 in step S301. The request interpreting/executing 
unit 102 forms data to be sent back to the Web browser on the basis of the 
received request (the respective processing operations in steps S302 to 
S304 and S306 to S309), and the transmitter/receiver 101 sends back the 
formed data to the Web browser (the processing in steps S305 and S3 10). 
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In step S500, the proxy server 100 checks using a file list get 
command if a file or directory named 7abc/def" is present in the CM 
server. According to the reply value of this command, it is determined 
that the above name indicates one of: 

a) a directory on the server; 

b) a file on the server, which is not checked out for modification; 

c) a file on the server, which is checked out for modification; and 

d) not present on the server. 

Subsequently, the flow advances to one of the following steps according 
to the determination result in the branch processing of steps S501, S502, 
and S504: 

step S503 (if the determination result is "a)") 

step S505 (if the determination result is "b)") 

step S506 (if the determination result is "c) ,! ) 

step S507 (if the determination result is "d)") 

The processing in step S503 will be explained below assuming 
that "/abc/def" is a directory name on the server. 

In step S503, a list of file directory names present under the 
directory f 7abc/def" on the CM server is acquired using a file list get 
command. Postulate that this command indicates there are three 
following files under the directory: 

xxx. html yyy.html zzz.html 

Then, the proxy server forms a text file described in the HTML 
language, as shown in FIG. 6. FIG. 6 shows an example of file list data 
formed by the proxy server in the first embodiment. The HTML 
language is the abbreviation for Hypertext Markup Language, is 
popularly used for displaying messages on the Web browser and the like, 
and is described in detail in references such as RFC- 1866. 

After that, the flow returns to the processing in step S3 10 in FIG. 
3, and the contents of the text file shown in FIG. 6 are sent back to the 
Web browser by the transmitter/receiver 101. Upon reception of the text 
file, the contents shown in FIG. 7 are displayed on the message display 
window of the Web browser. FIG. 7 shows the state wherein the Web 
browser displays the text file shown in FIG. 6. 

As can be verified from even a cursory review of this portion of Nakai, there is no teaching of 
the claimed feature, which is emphasized above. 

More specifically, claim 1 defines a system for file transfer between geographically 
and organizationally distant end points (a "customer repository" aka "client computer" at one 
end, and a set of "supplier repositories" aka "server computers" at the other end). This system 
utilizes as many common off-the-shelf components as possible, as is noted in many places in 
the specification of the present application {see e.g., paragraphs 0067-0071). 
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One unique component in the embodiments of the present application is what has 
been called the "transport gateway," and in particular its routing capability. The transport 
gateway resides between the client and the plurality of repository servers; when the client 
performs file transfer with a repository server of some kind, it connects to the gateway, not 
the repository server directly; rather, the gateway picks the right repository server (using the 
routing capability) and connects to it on the client's behalf. 

By this routing capability, the client does not have to know what repository server to 
connect, nor tell the transport gateway what repository server to connect. Instead, the client 
tells the gateway (by means of routing tokens included by the client in its request) some 
attribute(s) about the client context that the gateway will understand, and the gateway maps 
from those attribute(s) into the precise repository server that is appropriate for that context. 
For example, the client might provide routing tokens in its request describing the user itself: 
the type of organization (private business, government agency, etc), the type of business 
relationship the user has with the supplier of the gateway and repository server (support 
customer, vendor, etc), the scale of organization (small/home office, mid-size, enterprise, 
etc), the location of the user (e.g, country), etc.. As another example, the client might provide 
routing tokens in its request describing the file being transferred: the nature of its content 
(hardware diagnostic report, software inventory report, executable software, purchase order, 
etc), the name of the application that produced it or for which it is intended, etc. In each case, 
these routing tokens "describe" the context of the particular client request. The gateway then 
chooses the right repository server that the supplier has designated as appropriate for handling 
file transfers for that context. This component (which component is more fully explained in 
the specification), among others, clearly defines claim 1 over the cited because it abstracts the 
repository servers to the client. Therefore, when repository servers change - which 
realistically happens all the time in a large supplier organization - the gateway's routing 
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capability shelters the customer from that change. The customer merely continues to describe 
his request context in the same way, and the supplier merely changes the routing rules to 
adapt to the change in the repository server pool accordingly. This solves one of the major 
potential breakage points in any large-scale long-term data-exchange architecture (e.g., shifts 
in topology). 

In contrast to the features of claim 1, the teachings of Nakai are quite different. In this 
regard, and in contrast to the system of the present application, the system of Nakai is directed 
simply to an "information processing apparatus," in which a proxy server, disposed between 
the client and server, intervenes in communications between the client and server. In this 
regard, the proxy server specifies (using the precise IP address or server name of the end 
server, as specified by the client) a server based on the request, and determines the 
communication protocol to be used in the communication, (see Nakai, col. 5, line 47, which 
shows their client requests all specify the exact end-server machine name - or IP address). 
This is also suggested from all of the examples discussed in the Nakai spec — e.g., col. 5 lines 
13-15, col. 5 lines 51-65, col. 6 lines 55-65, etc. 

The foregoing description has been provided merely to assist the Examiner's in 
understanding of an operation embodiment of claim 1. For purposes of defining claim 1 over 
the cited Nakai reference, suffice it to say that Nakai fails to disclose the "selecting a 
repository . . . based on one or more routing tokens. . ." element of this claim, and for at least 
this reason the rejection should be withdrawn. 

Dependent Claims 2-11 

Claims 2-11 each depend from claim 1, and therefore patently define over the 
applied art for at least the same reasons described above. 
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Independent Claim 12 

The Office Action rejected independent claim 12 under 35 U.S.C. § 102(b) as 
allegedly anticipated by Nakai. For at least the reasons set forth below, Applicant 
respectfully traverses these rejections. 

Claim 12 recites: 

12. A method of transferring file information between one or more 
client computers and one or more server computers over a global-area 
computer network, the method comprising: 

receiving a file transfer request from a client computer; 

selecting a repository on one of the server computers based on one 
or more routing tokens in the file transfer request, wherein the routing 
tokens include one or more attributes describing the file, the client 
computer or an originator of the file transfer request; and 

performing the requested file transfer. 

{Emphasis added.) Applicant respectfully submits that the rejection is misplaced for at least 

the reason that the cited art does not disclose the features emphasized above. 

The features emphasized above closely parallel the distinguishing features of claim 1 , 
which have been fully described above. Applicant, accordingly, submits that claim 12 
patently defines over the cited art for at least the same reasons described above in connection 
with claim 1. Therefore, Applicant submits that the rejection of claim 12 be withdrawn. 

Dependent Claims 13-18 

Claims 13-18 each depend from claim 12, and therefore patently define over the 
applied art for at least the same reasons described above. 

Independent Claim 19 

The Office Action rejected independent claim 19 under 35 U.S.C. § 102(b) as 
allegedly anticipated by Nakai. For at least the reasons set forth below, Applicant 
respectfully traverses these rejections. 

Claim 19 recites: 
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19. A computer-readable storage medium comprising a routing 
computer program executable by a transport gateway connected to one or 
more client computers and one or more server computers, the transport 
gateway computer program comprising computer instructions for: 

receiving a file transfer request from a client computer; 

selecting a repository on one of the server computers based on one 
or more routing tokens in the file transfer request, wherein the routing 
tokens include one or more attributes describing the file, the client 
computer or an originator of the file transfer request; and 

performing the requested file transfer. 

(Emphasis added.) Applicant respectfully submits that the rejection is misplaced for at 
least the reason that the cited art does not disclose the features emphasized above. 

. The features emphasized are identical to the features emphasized in independent claim 
12, above closely parallel the distinguishing features of claim 1, which have been fully 
described above. Applicant, accordingly, submits that claim 12 patently defines over the 
cited art for at least the same reasons as claim 12. Therefore, Applicant submits that the 
rejection of claim 19 be withdrawn. 

Dependent Claims 20—29 

Claims 20-29 each depend from claim 19, and therefore patently define over the 
applied art for at least the same reasons described above. 

Independent Bases of Patentability of Claims 9-11 and 27-29 

In addition to the fact that claims 9-11 and 27-29 depend from claims 1 and 19 

(respectively), and therefore patently define over the cited art for at least the same reasons 

set forth in connection with claims 1 and 19 above, Applicant further traverses the rejection 

of claims 9-11 and 27-29 as improper. 

The Office Action rejected claims 9-11 and 27-29 as allegedly obvious over the 

combination of Nakai and Schloss. In forming this rejection, the Office Action merely 
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concluded that the combination of these two references would have been obvious "because 

it offers the advantage of allowing the fetching of information by any authorized user . . . 

from any cooperating computer on the Internet by simply clicking on a link/' (Office 

Action, paragraph No. 14). Applicants respectfully submit that this rejection falls far short 

of the legal requirements for forming rejections under 35 U.S.C. § 103(a). In this regard, 

it is well-settled law that in order to properly support an obviousness rejection under 35 

U.S.C. § 103, there must have been some teaching in the prior art to suggest to one skilled in 

the art that the claimed invention would have been obvious . W. L. Gore & Associates, Inc. 

v. Garlock Thomas, Inc. , 721 F.2d 1540, 1551 (Fed. Cir. 1983). More significantly, 

"The consistent criteria for determination of obviousness is whether the prior 
art would have suggested to one of ordinary skill in the art that this [invention] 
should be carried out and would have a reasonable likelihood of success, 
viewed in light of the prior art. ..." Both the suggestion and the expectation of 
success must be founded in the prior art, not in the applicant's disclosure... In 
determining whether such a suggestion can fairly be gleaned from the prior 
art, the full field of the invention must be considered; for the person of 
ordinary skill in the art is charged with knowledge of the entire body of 
technological literature, including that which might lead away from the 
claimed invention. " 

(Emphasis added) In re Dow Chemical Company , 837 F.2d 469, 473 (Fed. Cir. 1988). 

In this regard, Applicants note that there must not only be a suggestion to combine the 
functional or operational aspects of the combined references, but that the Federal Circuit also 
requires the prior art to suggest both the combination of elements and the structure resulting 
from the combination. Stiftung v. Renishaw PLC , 945 Fed.2d 1173 (Fed. Cir. 1991). 
Therefore, in order to sustain an obviousness rejection based upon a combination of any two 
or more prior art references, the prior art must properly suggest the desirability of combining 
the particular elements to create a message passing system as defined by the pending claims. 

When an obviousness determination is based on multiple prior art references, there 
must be a showing of some "teaching, suggestion, or reason" to combine the references. 
Gambro Lundia AB v. Baxter Healthcare Corp. , 110 F.3d 1573, 1579, 42 USPQ2d 1378, 
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1383 (Fed. Cir. 1997) (also noting that the "absence of such a suggestion to combine is 
dispositive in an obviousness determination"). 

Evidence of a suggestion, teaching, or motivation to combine prior art references 
may flow, inter alia , from the references themselves, the knowledge of one of ordinary 
skill in the art, or from the nature of the problem to be solved. See In re Dembiczak , 175 
F.3d 994, 1000, 50 USPQ2d 1614, 1617 (Fed. Cir. 1999). Although a reference need not 
expressly teach that the disclosure contained therein should be combined with another, the 
showing of combinability, in whatever form, must nevertheless be "clear and particular." 
Dembiczak , 175 F.3d at 999, 50 USPQ2d at 1617. 

If there was no motivation or suggestion to combine selective teachings from 
multiple prior art references, one of ordinary skill in the art would not have viewed the 
present invention as obvious. See In re Dance , 160 F.3d 1339, 1343, 48 USPQ2d 1635, 
1637 (Fed. Cir. 1998); Gambro Lundia AB , 110 F.3d at 1579, 42 USPQ2d at 1383 ("The 
absence of such a suggestion to combine is dispositive in an obviousness determination."). 

Significantly, where there is not apparent disadvantage present in a particular prior 
art reference, then generally there can be no motivation to combine the teaching of another 
reference with the particular prior art reference. Winner Int'l Royalty Corp. v. Wang , No 
98-1553 (Fed. Cir. January 27, 2000). The Office Action has failed to cite any apparent 
disadvantage of Nakai, which would prompt the combination of select teachings of Schloss 
therewith. 

For at least this separate and independent basis, the rejections of claims 9-11 and 
27-29 should be withdrawn. 
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CONCLUSION 

Applicants respectfully submit that all claims are in proper condition for allowance, and 
respectfully request that the Examiner pass this case to issuance. If, in the opinion of the 
Examiner, a telephonic conference would expedite the examination of this matter, the Examiner 
is invited to call the undersigned attorney at (770) 933-9500. 

No fee is believed to be due in connection with this Response to Non-Final Office 
Action. If, however, any fee is deemed to be payable, you are hereby authorized to charge 
any such fee to Hewlett-Packard Company's Deposit Account No. 08-2025. 

Respectfully submitted, 




Daniel R. McClure 
Registration No. 38,962 
(770) 933-9500 

Please continue to send all future correspondence to: 

Hewlett-Packard Development Company, L.P. 
Intellectual Property Administration 
P.O. Box 272400 

Fort Collins, Colorado 80527-2400 
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